你的客戶穿著筆挺西裝、頭髮梳得一絲不苟，清了清喉嚨，用不容置疑的語氣說：「這個專案，我需要一份完整的時程規劃，包含未來六個月所有功能的交付日期、預算，以及詳細的規格。我要確切地知道，我付的每一分錢，會在什麼時候變成什麼東西。」

你點點頭，感受到一股巨大壓力，但是也可以理解客戶的要求，畢竟這是一筆金額不小的專案費用，任誰都會擔心付的錢沒有拿到該有的成果。

話音剛落，你身旁的技術主管站了起來，在白板上畫了幾個圓圈和箭頭：「不行！現在是2025年了，我們是敏捷團隊！我們擁抱不確定性，透過兩週一次的 Sprint，經過快速迭代來交付價值，所以我們不可能預測六個月後的事，那跟算命沒兩樣！」

會議室的空氣瞬間凝結。客戶的臉色從期待變成懷疑，技術主管的眼神從熱情變成堅定。而你，作為 PM，又再次被推上了風口浪尖。

選了瀑布，得罪了相信技術自由的技術主管；選了敏捷，得罪了給你錢的客戶爸爸。你的胃，又開始翻滾絞痛了。

症狀診斷

如果你常常被要選敏捷還是瀑布的二選一問題困擾，那麼我會認為你可以被確診為「方法論選擇困難症」。

病根在於，許多人誤把「瀑布」和「敏捷」當成了兩個水火不容的宗教派別，以為專案的成功，取決於你是否對其中一個信仰足夠虔誠。但就像醫生診斷一樣，通常不會是某個單一學派的信徒唯一，反而通常會是懂得針對不同的病症，開立最合適的複方藥，甚至會中西合璧的安排治療計畫。

我想嘗試用更簡單的比喻來解釋這兩者：

• 瀑布式就像蓋房子。你必須先有完整的建築藍圖，打好地基，然後一層一層往上蓋。它適用於目標明確、需求穩定的專案。
• 敏捷式就像做一道創意料理。你會邊做邊嚐味道，隨時調整香料和火候。它適用於目標不確定、需要不斷探索的專案。

任何一個方法論都是可行的，它們都指向一個理想的狀態。但專案的現實，更像是在一間還在施工、而且時不時會停電的廚房裡，要你辦一場國宴。在這種情況下，死守著建築藍圖或米其林食譜都一樣可笑。我們的責任，就是在這個充滿各種不理想的混亂狀況中，依然要讓專案順利交付出它的價值與成果。

臨床案例

團隊的技術主管堅信敏捷開發是解決團隊效率問題的萬靈丹，因此下定決心，要求團隊必須全面導入敏捷開發的 Scrum 框架，當時身為 PM 菜比八的我也覺得如果採取 Scrum 的確是一個很棒的運作方式，於是就在上完課程以後開始成為推動 Scrum 的一員。

然而，我們的開發團隊是全公司「唯一」在跑敏捷的團隊，所有跟團隊協作的單位，不論是提出需求的業務部門、負責決策的高層等等，並沒有因為我們跑 Scrum 而有任何的改變，可想而知就發生了慘案。

首先是彼此對期望值有著巨大斷層： 團隊在第一次 Sprint Review 中，展示了一個核心功能可運作的最小可行性產品 MVP。但在需求方眼中，這是一個「缺少了另外八個次要功能」的半成品。他們的反應不是提供回饋，反而是滿滿的疑惑：「為什麼你們只做了一點點？那麼剩下的什麼時候能做完？」。

再來是我想邀請需求方參與每個 Sprint 的規劃會議，但在需求方的角度看來，這是打擾他們工作的「無效會議」，因為他們認為「需求一開始已經說得很清楚了，為什麼還需要每兩週又要再開一次會議」，把這個時間直接拿來趕快開發更實在。

於是在各種因素影響下，團隊的 Sprint 計畫總是頻繁地因為外部依賴而延誤，最終導致團隊的 Sprint 目標頻繁失敗，在其他部門眼中，這個跑敏捷的團隊，成了一個「承諾總是跳票、計畫一直在變」的不可靠單位。

現在的我回想起來，總結就是太菜了。

不僅僅是太過相信當時的技術主管說詞，也還有當初我也把跑敏捷完全視為一個非黑即白的方法選擇題，忽略了這背後其實還有其他關聯「組織文化」與「協作模式」的系統性問題。當方法論與組織現實脫節、沒有連貫的配套措施時，再好的初衷都可能導致災難性的後果。

處方籤

忘掉那些關於「敏捷 vs. 瀑布」的宗教戰爭吧！一個專業的 PM，從不問「該選哪一邊」，以下的問題幫助你快速判斷，你眼前的專案究竟是一道能照著食譜做的家常菜，還是一片需要你帶著開山刀進去的熱帶雨林。

第一部分：關於「目標與價值」

1. 目標清晰度： 專案的最終產出，是否像「蓋一棟有詳細藍圖的房子」一樣清晰明確？
   • 是 → 瀑布傾向
   • 否 → 敏捷傾向
2. 需求穩定度： 專案的需求，在未來幾個月內，改變的可能性高嗎？
   • 低 → 瀑布傾向
   • 高 → 敏捷傾向
3. 價值可衡量性： 我們是否有一組清晰的關鍵指標（KPIs），來客觀衡量專案的成功與否？
   • 是 → 瀑布傾向 (已有清晰指標能評估成功與否，適合預先規劃)
   • 否 → 敏捷傾向 (需要透過持續交付來驗證價值，適合迭代探索)
4. 市場未知度： 我們對於目標市場或使用者的反應，是否有足夠的數據支撐，還是需要大量的假設與探索？
   • 低 → 瀑布傾向 (已有足夠市場數據，不需太多探索)
   • 高 → 敏捷傾向 (還需要大量實驗與使用者回饋補足未知)
5. 上市時機價值： 如果我們必須在「更快推出基本功能」和「花更多時間打造完整方案」之間做選擇，哪個對業務更有利？
   • 完整方案更重要 → 瀑布傾向 (能提供所有功能的完整解決方案比速度更重要)
   • 速度更重要 → 敏捷傾向 (盡快推出基本功能到市場比完整性更重要)

第二部分：關於「方法與技術」

1. 技術確定性： 我們團隊對要使用的技術，是否已經非常熟悉？
   • 是 → 瀑布傾向
   • 否 → 敏捷傾向
2. 解法明確度： 解決這個問題的路徑，是已經有標準 SOP 答案，還是需要我們邊走邊發明輪子？
   • 是 → 瀑布傾向
   • 否 → 敏捷傾向
3. 相依性複雜度： 我們的專案是否高度依賴其他團隊或外部系統？這些依賴關係是否穩定可控？
   • 低 → 瀑布傾向
   • 高 → 敏捷傾向
4. 可測試性： 專案的產出是否容易被拆分成小單元進行測試與驗證？
   • 否 → 瀑布傾向
   • 是 → 敏捷傾向
5. 架構彈性： 現有的系統架構，是否能支持快速的修改與迭代？
   • 低 → 瀑布傾向
   • 高 → 敏捷傾向

第三部分：關於「團隊與環境」

1. 利害關係人參與度： 關鍵的決策者或客戶，是否能承諾在專案期間，高頻率地參與討論並提供回饋？
   • 否 → 瀑布傾向
   • 是 → 敏捷傾向
2. 團隊自主性： 團隊成員是否有足夠的經驗與授權，可以自行做出大部分的執行層決策？
   • 低 → 瀑布傾向 (團隊需要更多指導和監督，適合明確的階段性規劃)
   • 高 → 敏捷傾向 (團隊能自主決策並解決問題，適合快速迭代方式)
3. 組織容錯度： 公司的文化是鼓勵「快速失敗、快速學習」，還是傾向於懲罰任何的失誤？
   • 低 → 瀑布傾向 (較少容許失敗的環境，需要更多前期規劃)
   • 高 → 敏捷傾向 (允許嘗試與學習的環境，適合迭代方式)
4. 外部約束力： 是否有像「雙十一」這樣，來自外部的、絕對不能妥協的死線或預算？
   • 高 → 瀑布傾向 (外部有明確時程限制時，常需精確規劃)
   • 低 → 敏捷傾向 (較有彈性調整時程的空間)
5. 決策一致性： 專案中的關鍵人物（如客戶、經理、團隊負責人）是否對「什麼樣的結果才算成功」有共同的理解？
   • 大家意見一致 → 瀑布傾向 (容易形成明確的計畫)
   • 還有不同意見 → 敏捷傾向 (需要透過頻繁迭代來調整方向)

檢視完整個問卷後，你可能會發現你的專案在某些問題上偏向瀑布，在另一些問題上又偏向敏捷。這正是真實世界的常態！幾乎沒有任何專案是純粹的「100% 瀑布」或「100% 敏捷」。

所以基本上你需要根據你專案的特性，創造一個「混合藥方」：

1. 識別你的專案「核心性質」： 從上面的三大部分（目標與價值、方法與技術、團隊與環境）中，哪一部分對你的專案成功最為關鍵？那部分的總體傾向是什麼？
2. 根據性質調整開發方法： 如果你發現在「目標與價值」部分明顯偏向瀑布，那麼或許在專案初期，的確需要花更多時間在整體規劃上；反之，如果「團隊與環境」明顯偏向敏捷，那麼就應該讓團隊保持較高的自主性。
3. 混搭最佳實踐： 從兩種方法論中提取最適合你專案的元素。比如，你可以採用敏捷的短衝迭代方式，同時保留瀑布式的整體里程碑規劃。

對了，以上處方籤提供的分析問題框架就是一個參考方向，並非絕對無誤的教條。

每一個專案本來就會有其獨特的人、環境和需求，因此判斷的結果應該是一個光譜，而非非黑即白的選擇。在處方籤中整理、提供的問題和傾向評估方式，只是基於我個人目前的經驗和觀察，絕非放諸四海皆準的真理。

如果你根據自己的專案評估後得出的結論與我不同，請務必相信你自己的判斷！畢竟，你才是最了解自己專案情境的人。這些問題的目的，不是要給你一個「標準答案」，而是幫助你從多角度思考專案的特性，進而找到最適合你的方法論組合。

記住，方法論的目的是服務專案，而非專案來服務方法論。

成功的專案管理不在於你選擇了什麼方法論，而在於你能否根據實際情況，靈活地調整和應用不同的工具和技術，確保團隊高效協作，準時交付有價值的產品。

B 計畫：當你遇到「唯一教義派」時

好，我們來談談那個最讓人頭痛的「但是」。

但是，如果你的老闆或客戶，就是一個「瀑布教」或「敏捷教」的虔誠信徒，堅持要你就是只能用一種你評估與專案體質不符的方法論，該怎麼辦？

狀況一：被迫執行瀑布式 → 明修棧道，暗渡陳倉

1. 表面順從，給他要的： 你就花時間，做出那份他想要的、看起來很完美的甘特圖。但你要在旁邊附上一個巨大的星號，註明：「此計畫基於目前的假設，未來可能因市場變化而調整。」
2. 底下變通，做你想做的： 關起門來，你跟你的團隊，依然按照兩週一次的衝刺在工作。
3. 定期展示成果： 每兩週，就拿著一個可用的產品 increment 給老闆看，讓他親眼看到產品在進步，體會這個「活生生的成果」，比「靜態的甘特圖」更有價值。

狀況二：被迫執行敏捷式（如臨床案例 :D）→ 建立防火牆與翻譯機

1. 向上管理與教育： 花時間向你的主管和需求方「佈道」，用他們能聽懂的商業語言（如：降低風險、節省成本、及早驗證市場）來解釋你想推動的作法，爭取他們的理解與支持。
2. 建立「協作契約」： 在開始前，就和需求方明確約定好彼此的角色與責任。例如：Product Owner 的權責、需求方需要投入的時間（如參加 Sprint Review）、決策的時效性等。
3. 優先選擇 Kanban ： Kanban 不強制規定固定的時間迭代週期，更專注於固定、有限的 WIP 數量，也能幫助團隊將整體工作流程的可視化。如果團隊常要應對來自四面八方的「插單」，那麼使用 Kanban 也能讓外部協作者清晰地看到目前的工作流與瓶頸。

最後的醫囑

下次當有人問你「你信敏捷還是信瀑布？」時，請微笑著回答：

「我信專案能成功交付該有的價值。」

教科書教我們完美的流程，那是達到最佳狀態的理想路徑。但現實的專案充滿了各種不理想的狀況。我們身為有領薪水的專業職場人，責任就是在這個混亂的廚房裡，不管瓦斯夠不夠、醬油有沒有打翻，依然要想辦法端出一道能吃的菜，交付專案的價值與成果。

管他黑貓白貓，能抓老鼠的就是好貓。一個專業的 PM，從不效忠於任何方法論。我們只效忠於一件事：依照現有的環境與狀況，做出最務實的調整，而不是死守規則。

我們的工具箱裡，永遠放著各種五花八門的道具，在修理房子屋頂漏水的時候用鐵鎚，在做心臟手術的時候用手術刀，這才是真正的專業。

現在回想起自己當時剛接觸、認識敏捷後的樣子，根本有如下圖這樣 XD